https://modernanalyst.com RSS feeds for Business Analyst Community & Resources | Modern Analyst 60 https://modernanalyst.com/Resources/Articles/tabid/115/ID/185/Difference-Between-Systems-Analyst-and-Business-Analyst.aspx#Comments 1 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=185 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=185&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/185/Difference-Between-Systems-Analyst-and-Business-Analyst.aspx Many run into the problem of differentiating between a systems analyst and a business analyst. The differences in some organizations do not exist. In other companies, the comparison is almost an insult. Depending on the business or corporation, there are many differences. The job title is not the only thing with which to compare these two separate roles. The problem occurs when the title is not so conclusive. The business systems analyst or the systems business analyst can actually be one or the other or both. Job description is the only way to tell when this happens. There are differences, though. Author: Tony de Bree admin Sun, 20 May 2012 05:15:00 GMT f1397696-738c-4295-afcd-943feb885714:185 https://modernanalyst.com/Resources/Articles/tabid/115/ID/616/Lessons-Learnt-A-Year-in-Review.aspx#Comments 2 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=616 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=616&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/616/Lessons-Learnt-A-Year-in-Review.aspx It has been just over a year since I published my book, and that makes it easier for me to measure what has happened since then. I have spent this year visiting many companies and discussing their business analysis function. In some cases, I have performed an assessment on the business analysts as well as the business analysis function within many large Corporates. It has now got to the point where I could document the findings before I start the investigation. The reason for this is that the problems are the same. From articles and discussions from other countries it appears the problems are similar the world over. These are the problems I encounter most often: admin Sun, 07 Dec 2008 04:00:00 GMT f1397696-738c-4295-afcd-943feb885714:616 https://modernanalyst.com/Resources/Articles/tabid/115/ID/617/Putting-the-User-Back-in-User-Acceptance-Testing.aspx#Comments 3 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=617 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=617&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/617/Putting-the-User-Back-in-User-Acceptance-Testing.aspx Why is it so challenging to get users involved in User Acceptance Testing (UAT)? Isn’t it called UAT because the users are the main participants? My experience has shown that involving users in all phases of the project, especially UAT, is the best way to ensure project success. This article will present a proven approach to increasing user involvement by addressing the problems with traditional approaches to UAT.   I recently worked on a project in which a major defect was found after the software application moved to production. This defect caused the users to perform three days of manual processes. Users on the IT project team worked countless overtime hours. The defect also resulted in a frustrated user group and business sponsor. The project team’s morale was low and the business users lost a great deal of confidence in the project team’s ability to deliver quality software solutions. To reduce the risk of making this crucial mistake in the future the project team improved the UAT approach by getting users more involved. admin Sat, 06 Dec 2008 17:00:00 GMT f1397696-738c-4295-afcd-943feb885714:617 https://modernanalyst.com/Resources/Articles/tabid/115/ID/283/Agile-RUP-Experiences-from-the-trenches.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=283 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=283&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/283/Agile-RUP-Experiences-from-the-trenches.aspx This article, actually a compilation of three articles, provides proven advice for applying agile strategies on IBM® Rational® Unified Process®, or RUP®, teams. The articles are written by Mark Lines, Joshua Barnes, and Julian Holmes respectively, co-founders of Unified Process Mentors (www.upmentors.com). These three have mentored literally thousands of practitioners around the world on all aspects of software development, conducted dozens of conference presentations, authored many publications, sat on advisory boards, and chaired user groups. They work with organizations around the world to make process theory practical, driving success through structured change and leading by example. My experience is that RUP, done right, is agile and that RUP encapsulates much of the advice needed to scale agile techniques successfully. The first article, Bringing Discipline to the Agile Lifecycle by Mark Lines, shows how RUP requirements management techniques and risk-driven lifecycle bring the level of discipline required in many organizations without losing the flexibility that is the hallmark of agile methods. He argues that you really don't want the requirements to change radically later in the lifecycle, and that a bit of up-front investment can radically reduce your cost, schedule, and overall project risk. The second article, Strategies for Bringing Agility to RUP by Joshua Barnes, approaches the software process challenge from the opposite direction. He suggests ways to improve your RUP-based process "in flight" -- many projects are started with fixed goals in mind and with rigid regulatory constraints placed upon them, yet once the team is partway through the project they realize that they can loosen up because the fixed goals aren't so fixed and the regulations aren't so rigid. The third article, Geographically Distributed Agile Teams: Enabling Individuals and Interactions with Processes and Tools by Julian Holmes, overviews strategies for improving collaboration within a distributed agile team. Achieving effective collaboration within a project team can be a difficult challenge for a co-located team, let alone a geographically distributed one. Julian provides advice for developing a collaborative team culture while still maintaining consistency of approach, delivery, and management of shared work products.  Authors: Mark Lines, Joshua Barnes, Julian Holmes, Scott W. Ambler, admin Sun, 02 Mar 2008 06:37:00 GMT f1397696-738c-4295-afcd-943feb885714:283 https://modernanalyst.com/Resources/Articles/tabid/115/ID/236/Best-Practice-with-Structured-Requirements.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=236 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=236&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/236/Best-Practice-with-Structured-Requirements.aspx Analysts report poor requirements management accounts for as much as 71 percent of software project failures. The main cause is the gap between (a) what the business team wants and how it communicates this, and (b) what IT understands and delivers. No matter how good a project development environment is, if the requirements captured in the first place are inaccurate or incomplete, then the project is destined for failure. The same fate awaits project plans that are structured around passive and unmeasurable module and task definitions rather than measurable, business-defined goals. It sounds obvious, but the current rate of project failure demonstrates that this is plainly a difficult task. The main challenge with a software project is that the end result is, essentially, invisible. It is not like building a house, where design anomalies are often clearly visible. Communication in technical projects can be problematic, both between the customer/user and the business analyst and between the business analyst and the development/QA team. As a result, there is often inaccurate or poor understanding of the project scope amongst stakeholders. Project estimation relies on “gut feel” and there is often an overreliance on having particular technical people involved. Similarly, project progress cannot be measured easily or accurately due to inaccessible or overly technical milestones. This increased risk to the project often results in cost overruns, late delivery or, worst of all, outright failure to deliver the system required. A structured approach to requirements capture and management resolves these problems and is the only way all stakeholders can be confident that all requirements have been understood and incorporated into the project plan. Author: Fergal McGovern, Product Manager, Optimal Trace Compuware Corporation admin Thu, 31 Jan 2008 07:38:00 GMT f1397696-738c-4295-afcd-943feb885714:236 https://modernanalyst.com/Resources/Articles/tabid/115/ID/197/What-is-Agile-Analysis.aspx#Comments 2 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=197 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=197&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/197/What-is-Agile-Analysis.aspx Agile analysis is being spoken of more and more frequently in the world of business analysts. This form of analysis is becoming more and more popular as the next generation of business owners comes into play. It is a more hands on approach to the business analysis. There is more communication. Face to face discussions occur more frequently. E-mails and faxes are becoming few and far between. So what is agile analysis? Author: Tony de Bree admin Tue, 20 Nov 2007 07:06:00 GMT f1397696-738c-4295-afcd-943feb885714:197 https://modernanalyst.com/Resources/Articles/tabid/115/ID/195/What-Makes-a-Good-Business-Analyst.aspx#Comments 1 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=195 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=195&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/195/What-Makes-a-Good-Business-Analyst.aspx There are several key points one needs to understand before deciding whether or not to become a business analyst. You may be qualified to do the job you were hired to do. Yet is it the job you wanted to do? Some analysts find themselves locked in a cubical writing reports all day, only to find the report was not used or even read. They realize they are in a dead end job going no-where fast. This is not the usual dream one has when becoming a business analyst. Author: Tony de Bree admin Tue, 20 Nov 2007 07:00:00 GMT f1397696-738c-4295-afcd-943feb885714:195 https://modernanalyst.com/Resources/Articles/tabid/115/ID/194/What-Are-Use-Case-Studies.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=194 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=194&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/194/What-Are-Use-Case-Studies.aspx A use case study is designed to describe a situation in which the program is being utilized by the end user. It will tell a story of sorts describing how the program works and the input of the user. It does not tell how the program was developed. The details of the programming are not included in the use case study. You are trying to express the concept behind the creation. Author: Tony de Bree admin Tue, 20 Nov 2007 06:55:00 GMT f1397696-738c-4295-afcd-943feb885714:194 https://modernanalyst.com/Resources/Articles/tabid/115/ID/193/The-Role-of-a-Business-Analyst.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=193 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=193&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/193/The-Role-of-a-Business-Analyst.aspx The role of a business analyst can be very difficult. He or she must wade through the mass of information presented to determine the underlying problems. This information may or may not be correct. The business analyst much research to comprehend the true situation of the business. The information supplied to the business analyst is given from many perspectives. Opinions can influence how one perceives the related issues. At times, the opinions can add unrelated information which only complicates the role of a business analyst. Author: Tony de Bree admin Tue, 20 Nov 2007 06:52:00 GMT f1397696-738c-4295-afcd-943feb885714:193 https://modernanalyst.com/Resources/Articles/tabid/115/ID/192/The-Job-Market-for-a-Business-Analyst.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=192 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=192&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/192/The-Job-Market-for-a-Business-Analyst.aspx Business analyst is not a new term in the business world. It has become extremely popular over the past few years. With businesses expanding world wide more emphasis has been put on the IT teams and departments to monitor and or expand with corporate peers. This has brought about changes in how business operates. A need for business analysis and systems analysts was born. Stakeholders wanted to know the money being spent was worth the expenditure. They needed someone to come in and tell them where to invest within the company to raise profits. The business analyst job was created. Author: Tony de Bree admin Tue, 20 Nov 2007 06:47:00 GMT f1397696-738c-4295-afcd-943feb885714:192 https://modernanalyst.com/Resources/Articles/tabid/115/ID/191/Reasons-Projects-Fail-for-a-Business-Analyst.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=191 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=191&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/191/Reasons-Projects-Fail-for-a-Business-Analyst.aspx Each day businesses call upon a business analyst to determine what must be done in order to accomplish a certain task. Each avenue must be explored and analyzed for a project proposal to be implemented. The project scope determines what the course of action may or may not be. Each person involved must answer to another until management is satisfied all has been done to rectify the situation. Everything stays on task. The project as a whole is coming together. Teams are co-ordinating with each other to apply the objective into the code. It is all going according to plan. At the end, it all falls apart. Nothing is as it seems. The project has failed to accomplish what it set out to do. The business analyst is hung out to dry. Every finger points to him or her. In actuality it is not the fault of the analyst. Author: Tony de Bree admin Tue, 20 Nov 2007 06:43:00 GMT f1397696-738c-4295-afcd-943feb885714:191 https://modernanalyst.com/Resources/Articles/tabid/115/ID/190/Qualities-of-a-Business-Analyst.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=190 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=190&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/190/Qualities-of-a-Business-Analyst.aspx Analysts used to be the ones who had a technology degree but were able to back it up with some basic business knowledge. Now the times are changing. Business analysts are business people who specialize in technology. They can work both spectrum's of the field. Author: Tony de Bree admin Tue, 20 Nov 2007 06:37:00 GMT f1397696-738c-4295-afcd-943feb885714:190 https://modernanalyst.com/Resources/Articles/tabid/115/ID/189/Is-a-Degree-Necessary-to-be-a-Business-Analyst.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=189 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=189&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/189/Is-a-Degree-Necessary-to-be-a-Business-Analyst.aspx The lack of proper education can be a major drawback for someone breaking into the business world. Many people study business management and other business related courses. There are many diplomas issued each year to hopeful business prospects. When it comes to being a business analyst all the rules change. Although a degree can be helpful, it is not necessary. Experience is the key to success when it comes to a business analyst. Author: Tony de Bree admin Tue, 20 Nov 2007 06:33:00 GMT f1397696-738c-4295-afcd-943feb885714:189 https://modernanalyst.com/Resources/Articles/tabid/115/ID/187/Hiring-a-Business-Analyst.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=187 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=187&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/187/Hiring-a-Business-Analyst.aspx There are times when a company must hire a business analyst. When searching from an outside source there are certain things an employer should determine when hiring the perfect business analyst. Some of these suggestions are common sense. Other items listed may be overlooked in the desperation to find a qualified business analyst. Author: Tony de Bree admin Tue, 20 Nov 2007 06:25:00 GMT f1397696-738c-4295-afcd-943feb885714:187 https://modernanalyst.com/Resources/Articles/tabid/115/ID/186/Finding-a-Business-Analyst.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=186 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=186&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/186/Finding-a-Business-Analyst.aspx There are times when a business starts to lose money and no-one is sure where the problem is located. Going over facts and figures only points to the bottom line. The bottom line continues to shrink. People start to get desperate. Strategies are planned and implemented to no avail. Tried and true measures are no longer working. It is time to call on the experts. The business analyst needs to be brought in. The problem is finding one who knows the company. Author: Tony de Bree admin Tue, 20 Nov 2007 06:19:00 GMT f1397696-738c-4295-afcd-943feb885714:186 https://modernanalyst.com/Resources/Articles/tabid/115/ID/184/Defining-a-Project-Scope.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=184 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=184&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/184/Defining-a-Project-Scope.aspx The project scope is the core of an individual project. Without a project scope the project will just float. Proper needs assessments and other intricate details will be overlooked. Each project is designed to resolve issues the stakeholders are experiencing in their company. These well meaning individuals will dump data and information charts, lists and figures presumptuously on the desk expecting it to all make sense. The "here's the problem, fix it" attitude can be frustrating. There are numerous feature requirements which must be met. It is unclear as to what to prioritize where. Cost estimates may not be accurate. Delivery dates are tentative. It is enough to make someone through up their hands in desperation and say "I QUIT!". The trained business analyst will just grin and dive in. He or she will know what is needed is a project scope. Author: Tony de Bree admin Tue, 20 Nov 2007 06:10:00 GMT f1397696-738c-4295-afcd-943feb885714:184 https://modernanalyst.com/Resources/Articles/tabid/115/ID/183/Customer-Relations-and-the-Business-Analyst.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=183 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=183&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/183/Customer-Relations-and-the-Business-Analyst.aspx In today's market the customer should always come first. This has been the bread and butter of many industries throughout the ages. A satisfied customer is one who will keep coming back. The customer is the one who helps the bottom line. This is true in the field of business analysis. It is the customer's needs which the business analyst is fulfilling. The business analyst should help to strengthen customer relations. Time put into this is time well spent. Finding the customer to be unhappy is never a good thing. Ask any good business manager what their number one priority is and they will answer customer relations. Sometimes it does not always show. Author: Tony de Bree admin Tue, 20 Nov 2007 06:04:00 GMT f1397696-738c-4295-afcd-943feb885714:183 https://modernanalyst.com/Resources/Articles/tabid/115/ID/182/Business-Analyst-for-the-Small-Business.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=182 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=182&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/182/Business-Analyst-for-the-Small-Business.aspx Small business owners may not think they need a business analyst. Small businesses are sometimes caught up in trying to survive and overlook a key element in their success. The business analyst can actually come in and determine what the small business owner can do to expand his or her business. The small business owner can benefit just as much from a business analyst as a large corporation. There may be times when the business analyst sees the big picture when the small business owner can only see the bottom line. The new small business may not feel the added expense of a business analyst is worth justifying. In fact this is just the case. Author: Tony de Bree admin Tue, 20 Nov 2007 05:57:00 GMT f1397696-738c-4295-afcd-943feb885714:182 https://modernanalyst.com/Resources/Articles/tabid/115/ID/181/Business-Analyst-Job-Description.aspx#Comments 2 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=181 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=181&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/181/Business-Analyst-Job-Description.aspx The job description of a business analyst is rather extensive. He or she must first determine the needs for a company by using many tools. The business analyst may conduct interviews with management and other department leaders. He or she must analyze documentation, facts and figures. The analyst should incorporate a site survey to determine applications being used and what may be needed for superior quality performance. He or she will consider business applications currently being used which may or may not be working. The business analyst will do a business analysis and a work flow analysis to assess difficulties in reaching goals and to determine a better strategy. Author: Tony de Bree admin Tue, 20 Nov 2007 05:51:00 GMT f1397696-738c-4295-afcd-943feb885714:181 https://modernanalyst.com/Resources/Articles/tabid/115/ID/180/Being-Flexible-as-a-Business-Analyst.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=180 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=180&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/180/Being-Flexible-as-a-Business-Analyst.aspx Sometimes the business analyst can be so caught up in a project he or she forgets tried and true methods do not always work. The analysis team is trying to get done what the customer has scoped out and sets up a plan of action. The plan of action requires certain fundamentals. There are times when these rudimentary ideas just do not work for the client. The client can not understand why these steps may be so important. This is when the business analyst needs to step back and ask the same questions as the client. It is all in communication. Author: Tony de Bree admin Tue, 20 Nov 2007 05:45:00 GMT f1397696-738c-4295-afcd-943feb885714:180 https://modernanalyst.com/Resources/Articles/tabid/115/ID/179/8-Questions-Every-Business-Analyst-Should-Ask.aspx#Comments 2 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=179 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=179&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/179/8-Questions-Every-Business-Analyst-Should-Ask.aspx It does not matter what project you are going to undertake. It is not important what industry you are going to be assessing. What is important is you know what you are going to do. You must as questions. You must find what it is the client wants. Presented is a list of obvious questions every good business analyst should know the answer to when starting a project. Author: Tony de Bree admin Tue, 20 Nov 2007 05:35:00 GMT f1397696-738c-4295-afcd-943feb885714:179 https://modernanalyst.com/Resources/Articles/tabid/115/ID/176/Challenges-of-the-Business-Analyst.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=176 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=176&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/176/Challenges-of-the-Business-Analyst.aspx The work of a business analyst is to develop an understanding of business process and model them. Usually the work is associated with a project whose objectives are to change or improve a process. Often these processes are quite complex and the analyst must get the information from many sources. Usually much of the information and ideas for improvement are in the heads of key users of the processes being studied. The challenge of the analyst is to get a good understanding of the process from these people. This task presents the analyst with many difficulties. A business analyst often encounters people who are not ready to cooperate for many reason. admin Fri, 16 Nov 2007 07:46:00 GMT f1397696-738c-4295-afcd-943feb885714:176 https://modernanalyst.com/Resources/Articles/tabid/115/ID/169/Advantages-of-User-Stories-for-Requirements.aspx#Comments 3 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=169 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=169&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/169/Advantages-of-User-Stories-for-Requirements.aspx Extreme programming (XP) introduced the practice of expressing requirements in the form of user stories, short descriptions of functionality–told from the perspective of a user–that are valuable to either a user of the software or the customer of the software. The following are typical user stories for a job posting and search site: A user can post her resume to the web site. A user can search for jobs. A company can post new job openings. A user can limit who can see her resume. But user stories are not just these small snippets of text. Each user story is composed of three aspects: Written description of the story, used for planning and as a reminder Conversations about the story that serve to flesh out the details of the story Tests that convey and document details that can be used to determine when a story is complete Author: Mike Cohn admin Tue, 06 Nov 2007 07:34:00 GMT f1397696-738c-4295-afcd-943feb885714:169 https://modernanalyst.com/Resources/Articles/tabid/115/ID/168/From-Use-Case-Diagrams-to-Context-Diagrams.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=168 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=168&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/168/From-Use-Case-Diagrams-to-Context-Diagrams.aspx As long as practitioners recognize that use case diagrams are optional and iconic (as opposed to schematic), they shouldn't have problems. The diagrams are useful, for example, on whiteboards as a way of sketching and framing an agenda while people are writing up and reviewing use case detail on index cards. The trouble starts, however, when projects end up with unreadable and overly complex use case diagrams. Those diagrams distract project members from the more useful endeavor of elaborating the use cases and result in wasted time. And the major value of the use case diagram -- showing the context of a software system -- ends up lost in a cloud of bubbles. Author: Kevlin Henney admin Sat, 03 Nov 2007 05:48:00 GMT f1397696-738c-4295-afcd-943feb885714:168 https://modernanalyst.com/Resources/Articles/tabid/115/ID/71/Habits-of-Effective-Analysts.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=71 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=71&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/71/Habits-of-Effective-Analysts.aspx  Software managers sometimes assume that every skilled programmer is also proficient at interviewing customers and writing requirements specifications, without any training, resources or coaching. This isn't a reasonable assumption. Like testing, estimation and project management, requirements engineering has its own skill set and body of knowledge. Unfortunately, most computer science educational curricula emphasize programming-related knowledge over other software life cycle activities. In addition, many software practitioners—including myself—lack formal education in their field. Self-study and on-the-job learning often neglect softer skills such as those needed in requirements engineering. The role of the requirements analyst (also called business analyst, systems analyst, requirements engineer or requirements manager) is critical to a software project. Many organizations expect developers or project managers to handle this vital function on their own. And even if a project team does include dedicated analysts, their skills might not be up to the task. Too often, I meet analysts who have had little training in how to perform their job and who have few books, articles or tools available to help them. Analysts who come from a user background may lack technical understanding, while those who migrated from the development world may not understand the user’s business domain. Every software organization should develop an experienced cadre of trained and knowledgeable requirements analysts, even though analysis might not be a full-time function on every project. An analyst provides a specialized capability that can make the difference between a project that succeeds and one that struggles. Here I describe several characteristics and practices of successful requirements analysts. Author: Karl Wiegers admin Thu, 06 Sep 2007 16:33:00 GMT f1397696-738c-4295-afcd-943feb885714:71 https://modernanalyst.com/Resources/Articles/tabid/115/ID/62/What-is-a-Business-Analyst.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=62 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=62&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/62/What-is-a-Business-Analyst.aspx Today the term Business Analyst is synonymous with a career in the IT industry but the most successful and valuable analysts are those who understand the 'business' rather than those who understand IT. So what exactly is a Business Analyst? What is the Business Analyst’s role? What is the best background for this job? What skill set is required? What type of person is the best fit? What training is required and available? Each organisation seems to have its own ideas about the role, skills, responsibilities and expectations of the Business Analyst. Given the importance of the job, a common definition would assist both practitioners and employers. We explore some of the issues here. Written by Derrick Brown, IRM's Director and instructional designer, it shares first hand observations and experience gained from training thousands of Business Analysts since 1980, first in the UK and since 1984 in Australia. Author: Derrick Brown admin Fri, 31 Aug 2007 19:45:00 GMT f1397696-738c-4295-afcd-943feb885714:62 https://modernanalyst.com/Resources/Articles/tabid/115/ID/51/Tips-for-Business-Analysts-Career-Paths-for-Business-Analysts.aspx#Comments 1 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=51 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=51&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/51/Tips-for-Business-Analysts-Career-Paths-for-Business-Analysts.aspx People come to the job of Business Analyst in many different ways. Some people graduate from college and immediately start to work as a junior Analyst for a major corporation. Often a Business Analyst has some years of work experience in some related field before starting to work as an analyst. You may choose to work for a company in the role of Business Analyst, or you may be a consultant and some of what you do is work as a Business Analyst. Once you are working as a Business Analyst, what can you expect in terms of career growth? Author: Geri Schneider Winters admin Wed, 15 Aug 2007 03:43:00 GMT f1397696-738c-4295-afcd-943feb885714:51 https://modernanalyst.com/Resources/Articles/tabid/115/ID/43/Business-Analysis-Center-of-Excellence.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=43 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=43&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/43/Business-Analysis-Center-of-Excellence.aspx The Cornerstone of Business Transformation. The fiercely competitive twenty-first century business environment poses challenges at every turn. Both public and for-profit organizations must be flexible and adaptable to remain competitive. It is through successful projects that organizations manage change, deliver new business solutions, and ultimately, achieve their strategies. However, we continue to struggle to manage complex business change initiatives. Organizations around the globe are striving to improve their business analysis capabilities to: (1) drive changes from strategic goals; (2) invest in the most valuable projects – those that deliver the highest value at the lowest cost and risk; and (3) execute projects optimally to achieve business benefits from the new solutions as quickly as possible. This paper explores our disappointing project performance track record, the nature of twenty-first century projects, the need for a central focus on business analysis as a critical component of organizational transformation, and the role of a business analysis center of excellence in organizations. Author: Kathleen B. Hass admin Fri, 10 Aug 2007 18:32:00 GMT f1397696-738c-4295-afcd-943feb885714:43 https://modernanalyst.com/Resources/Articles/tabid/115/ID/39/Eight-Things-Your-Business-Analysts-Need-to-Know.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=39 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=39&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/39/Eight-Things-Your-Business-Analysts-Need-to-Know.aspx Each year, organizations across the globe face astronomical project failure rates, often wasting millions of dollars per failed project. This paper examines the roots of project failure and centers in on the elusive, often undefined role of the business analyst. In response to research showing that many organizations have not set concrete requirements and job descriptions for their business analysts, this paper provides eight essential competencies necessary for success in this job function. It explores the essential skills, knowledge and abilities inherent to each competency and during each stage of a business analyst’s career. The paper concludes with practical tips for using these competencies as guidelines for improving the efficiency of business analysts within your organization. Author: ESI International admin Thu, 09 Aug 2007 20:49:00 GMT f1397696-738c-4295-afcd-943feb885714:39 https://modernanalyst.com/Resources/Articles/tabid/115/ID/38/Memoir-of-the-CBAP-Exam.aspx#Comments 1 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=38 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=38&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/38/Memoir-of-the-CBAP-Exam.aspx In this article from ESI Horizons newsletter, Chip Schwartz discusses his experiences with sitting for the first Certified Business Analyst Professional (CBAP) exam in November 2006. Author: Chip Schwartz admin Thu, 09 Aug 2007 20:34:00 GMT f1397696-738c-4295-afcd-943feb885714:38 https://modernanalyst.com/Resources/Articles/tabid/115/ID/13/Tips-for-Business-Analysts-What-are-RUP-EUP-UP-OpenUP-EssUp.aspx#Comments 1 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=13 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=13&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/13/Tips-for-Business-Analysts-What-are-RUP-EUP-UP-OpenUP-EssUp.aspx RUP describes a process for developing software systems. It seems there are so many variations of RUP, how do you know which is best for you and your organization, if any? What do all those acronyms mean? Where are these things coming from? Author: Geri Schneider Winters admin Fri, 03 Aug 2007 01:36:00 GMT f1397696-738c-4295-afcd-943feb885714:13 https://modernanalyst.com/Resources/Articles/tabid/115/ID/14/Tips-for-Business-Analysts-Requirements-in-Complex-Systems.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=14 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=14&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/14/Tips-for-Business-Analysts-Requirements-in-Complex-Systems.aspx Some of you may be working on systems with many complex relationships between the parts. These complex systems may be described as a system of systems, or may be described as a product line, or perhaps both at once. In these cases, you will often find that the requirements of a large, overall system are shared among a number of related projects, each of which implements some well-defined part of the overall system. Author: Geri Schneider Winters admin Wed, 25 Jul 2007 01:45:00 GMT f1397696-738c-4295-afcd-943feb885714:14 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3/Alternatives-of-Alternatives.aspx#Comments 2 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=3 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=3&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/3/Alternatives-of-Alternatives.aspx Geri Schneider Winters writes about whether or not you could write alternatives to alternatives in use cases. There is no actual standard for the formatting of a use case specification, just guidelines and best practices.  Therefore, if using alternatives to alternatives in use cases makes the use case more clear - use it, by any means. Author: Geri Schneider Winters admin Tue, 17 Jul 2007 03:32:00 GMT f1397696-738c-4295-afcd-943feb885714:3 https://modernanalyst.com/Resources/Articles/tabid/115/ID/4/Use-Cases-and-Reports.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=4 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=4&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/4/Use-Cases-and-Reports.aspx In this article, Geri Schneider Winters discusses the question of whether use cases can be used to document requirements for reports. Author: Geri Schneider Winters admin Tue, 10 Jul 2007 03:39:00 GMT f1397696-738c-4295-afcd-943feb885714:4 https://modernanalyst.com/Resources/Articles/tabid/115/ID/67/Database-Modelling-in-UML.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=67 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=67&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/67/Database-Modelling-in-UML.aspx When it comes to providing reliable, flexible and efficient object persistence for software systems, today's designers and architects are faced with many choices. From the technological perspective, the choice is usually between pure Object-Oriented, Object-Relational hybrids, pure Relational and custom solutions based on open or proprietary file formats (eg. XML, OLE structured storage). From the vendor aspect Oracle, IBM, Microsoft, POET and others offer similar but often-incompatible solutions. This article is about only one of those choices, that is the layering of an object-oriented class model on top of a purely relational database. This is not to imply this is the only, best or simplest solution, but pragmatically it is one of the most common, and one that has the potential for the most misuse. We will begin with a quick tour of the two design domains we are trying to bridge: firstly the object-oriented class model as represented in the UML, and secondly the relational database model. For each domain we look only at the main features that will affect our task. We will then look at the techniques and issues involved in mapping from the class model to the database model, including object persistence, object behaviour, relationships between objects and object identity. We will conclude with a review of the UML Data Profile (as proposed by Rational Software). Some familiarity with object-oriented design, UML and relational database modelling is assumed. Author: Geoffrey Sparks admin Thu, 05 Jul 2007 21:32:00 GMT f1397696-738c-4295-afcd-943feb885714:67 https://modernanalyst.com/Resources/Articles/tabid/115/ID/42/The-Business-Analyst-The-Pivotal-IT-Role-of-the-Future.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=42 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=42&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/42/The-Business-Analyst-The-Pivotal-IT-Role-of-the-Future.aspx The talents, competencies and heroics of project managers and technologists alone cannot drive value into the organization. For business needs and goals to be converted into innovative solutions that truly bring wealth to the enterprise, a stronger bridge must be built between the business and the technical communities. Enter the business analyst. Change is the norm, fierce competition is the driver, and lean thinking is the latest call to action. Information Technology (IT) has finally come into its own, now viewed as a value provider as opposed to a cost drain. With the stakes so high, IT organizations are faced with an extraordinary combination of pressures to deliver value to their organizations in terms of added revenues, avoided costs, lower taxes, higher productivity, less employee turnover, less risk exposure, etc. Competitive advantage is now linked to an organization’s ability to rapidly deploy IT solutions, and to change those systems as the business need evolves. IT projects must not only deliver high quality products faster, better, and cheaper (traditionally the responsibility of the project manager), they are also under intense scrutiny to positively impact the bottom line (increasingly, the joint responsibility of the project manager, project sponsor, and the business analyst). Author: Kathleen B. Hass admin Fri, 22 Jun 2007 18:22:00 GMT f1397696-738c-4295-afcd-943feb885714:42 https://modernanalyst.com/Resources/Articles/tabid/115/ID/44/Hot-Jobs-Business-Analyst.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=44 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=44&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/44/Hot-Jobs-Business-Analyst.aspx This article provides a high level description of the job of the Business Analyst as well as summary answers on questions such as "Why you need a business analyst?", "What are the desired skills for a business analyst?", "How to find business analysts?", etc. Author: Katherine Walsh admin Tue, 19 Jun 2007 20:00:00 GMT f1397696-738c-4295-afcd-943feb885714:44 https://modernanalyst.com/Resources/Articles/tabid/115/ID/40/Establishing-and-Maturing-a-Business-Analysis-Center-of-Excellence-The-Essential-Guide.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=40 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=40&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/40/Establishing-and-Maturing-a-Business-Analysis-Center-of-Excellence-The-Essential-Guide.aspx Many organizations are scratching their collective heads over how to build and mature a business analysis center of excellence (COE). Where do we start? What does a business analysis center of excellence look like? Who owns it? How does it evolve? This white paper outlines the standard operating practices necessary for a business analysis center of excellence and provides maturity level descriptions to help your organization determine the stage at which its business analysis practice is currently operating. It also offers step-by-step guidance not only on the specific mini-projects that comprise a center of excellence, but also on the bigger picture of business analysis best practices – such as how to gain the support you need by showing every level of the organization how they’ll benefit, and tips for planning and breaking down your overall goals into smaller, more manageable pieces. Author: ESI International admin Sat, 09 Jun 2007 21:01:00 GMT f1397696-738c-4295-afcd-943feb885714:40 https://modernanalyst.com/Resources/Articles/tabid/115/ID/58/The-Software-Requirements-Struggle.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=58 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=58&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/58/The-Software-Requirements-Struggle.aspx Traditional software development has always required a long requirements-gathering phase at the beginning of a project that, if not handled correctly, can often result in schedule delays and costly budget overruns that have a significant impact on the project itself.  Software simulation can streamline that process and prevent many of the errors and delays that are common when using traditional methods.  This paper details the requirements-gathering mechanism and how simulation is breaking into the mainstream as a time-and cost-saving method of helping clients design software projects with a minimum of error and hassle. Author: Jason Moccia admin Sat, 02 Jun 2007 03:41:00 GMT f1397696-738c-4295-afcd-943feb885714:58 https://modernanalyst.com/Resources/Articles/tabid/115/ID/45/Requirements.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=45 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=45&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/45/Requirements.aspx Maybe it was that southern drawl. Or maybe it was because I got mad. I'm not sure why I still remember this moment so clearly, but I do.  It happened when I was at Spyglass, over ten years ago.  Several of us developers were in a meeting with Steve Stone, then recently-hired as director of the Champaign office.  We were talking about a possible new feature.  Steve, in his Alabama accent, asked, "So is that a requirement?" A couple years later, I realized that I misunderstood the question.  I didn't have enough project management background to know the particular way that he was using the word "requirement".  For me at the time, the word "requirement" had connotations of absolute necessity.  So when Steve asked the question, here is what I heard: "So is this feature something that absolutely must be in the next release of the product?" On top of that, I'll confess I was sort of generally crabby at that point in my life, especially with respect to Steve Stone.  Instead of promoting me or one of the other lead developers to run the Champaign office, Spyglass had hired Steve from the outside.  In fact, Spyglass asked me to interview Steve, but only after the interview did they tell me I had actually been interviewing my new boss. Anyway, I was in a generally foul mood when I misunderstood this question.  I suppose that's why I answered Steve by saying something like this: "How the @%$* should I know if this feature has to be in the product or not?  You're new here, so let me explain how things go.  Management moved the headquarters to Chicago after years of promising that they never would.  Here in Champaign, nobody tells us anything.  We've got no marketing people except the team who spent 3 months deciding which Pantone color is the right shade of red for our company logo, which nobody ever sees because our product is an OEM component.  The only way we ever know that a feature absolutely must be in the product is when one of our Sales Guys calls up and tells us that he already promised it." Steve was a very patient man.  I assume anybody who lived in Alabama would have to be.  :-)  He just smiled as he listened to my rant (footnote 1). But my career with Spyglass didn't last too much longer after that.  A few months later, in a moment when I was ready to throw another tantrum, I decided to just quit instead. And I went out on my own and founded SourceGear.  We started out doing contracting projects.  One of our first clients asked me for a Software Requirements Specification (SRS) and a Traceability Matrix.  That wasn't a very good day. But not long after that, I learned what the word "requirement" means when used in the context of software project management. And I learned what Steve Stone had really meant when he asked that infuriating question.  When Steve said: "So is that a requirement?" What he was really asking was: "So it sounds like we just identified something that should become part of our spec.  You guys have a spec around here somewhere, right?  Who is responsible for updating that spec to capture this new item?" (Poster's note: Great article on requirements from the developer's perspective.  Read the full article) Author: Eric Sink admin Mon, 14 May 2007 10:01:00 GMT f1397696-738c-4295-afcd-943feb885714:45 https://modernanalyst.com/Resources/Articles/tabid/115/ID/68/The-Use-Case-Model.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=68 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=68&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/68/The-Use-Case-Model.aspx The Use Case Model describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single unit of meaningful work; for example login to system, register with system and create order are all Use Cases. Each Use Case has a description which describes the functionality that will be built in the proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its own behaviour. Author: Sparx Systems admin Tue, 17 Apr 2007 21:35:00 GMT f1397696-738c-4295-afcd-943feb885714:68 https://modernanalyst.com/Resources/Articles/tabid/115/ID/49/Painless-Functional-Specifications--Part-4-Tips.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=49 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=49&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/49/Painless-Functional-Specifications--Part-4-Tips.aspx In this fourth and final part of the series I'll share some of my advice for writing good specs. The biggest complaint you'll hear from teams that do write specs is that "nobody reads them." When nobody reads specs, the people who write them tend to get a little bit cynical. It's like the old Dilbert cartoon in which engineers use stacks of 4-inch thick specs to build extensions to their cubicles. At your typical big, bureaucratic company, everybody spends months and months writing boring specs. Once the spec is done, it goes up on the shelf, never to be taken down again, and the product is implemented from scratch without any regard to what the spec said, because nobody read the spec, because it was so dang mind-numbing. The very process of writing the spec might have been a good exercise, because it forced everyone, at least, to think over the issues. But the fact that the spec was shelved (unread and unloved) when it was completed makes people feel like it was all a bunch of work for naught. Also, if your spec never gets read, you get a lot of arguments when the finished product is delivered. Somebody (management, marketing, or a customer) says: "wait a minute! You promised me that there would be a Clam Steamer! Where's the clam steamer?" And the programmers say, "no, actually, if you look on the spec on chapter 3, subchapter 4, paragraph 2.3.0.1, you'll see it says quite explicitly 'no clam steamer.'" But that doesn't satisfy the customer, who is always right, so the grumpy programmers have to go retrofit a clam steamer into the thing (making them even more cynical about specs). Or a manager says, "hey, all the wording on this dialog is too verbose, and there should be an advertisement at the top of every dialog box." And the programmers say, in frustration, "but you approved the spec which precisely listed the layout and contents of every dialog box!" But of course, the manager hadn't actually read the spec, because when he tried, his brain started seeping out through his eye sockets, and anyway, it was interfering with his Tuesday golf game. So. Specs are good, but not if nobody reads them. As a spec-writer, you have to trick people into reading your stuff, and you should also probably make an effort not to cause any already-too-small brains to leak out through eye-sockets. Tricking people into reading your stuff is usually just a matter of good writing. But it's not fair of me to just say "be a good writer" and leave it at that. Here are four easy rules that you absolutely must follow to make specs that get read. Author: Joel Spolsky admin Sat, 14 Apr 2007 10:31:00 GMT f1397696-738c-4295-afcd-943feb885714:49 https://modernanalyst.com/Resources/Articles/tabid/115/ID/48/Painless-Functional-Specifications--Part-3-But-How.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=48 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=48&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/48/Painless-Functional-Specifications--Part-3-But-How.aspx Now that you've read all about why you need a spec and what a spec has in it, let's talk about who should write them. Who writes specs? Let me give you a little Microsoft history here. When Microsoft started growing seriously in the 1980s, everybody there had read The Mythical Man-Month, one of the classics of software management. (If you haven't read it, I highly recommend it.) The main point of that book was that when you add more programmers to a late project, it gets even later. That's because when you have n programmers on a team, the number of communication paths is n(n-1)/2, which grows at O(n2). So the programmers at Microsoft were worried about how to write bigger and bigger programs, when the prevailing wisdom of the day was that adding programmers just makes things worse. Charles Simonyi, Microsoft's long time "chief architect", suggested the concept of master programmers. The idea was basically that one master programmer would be responsible for writing all the code, but he or she would rely on a team of junior programmers as "code slaves". Instead of worrying about debugging every function, the master programmer would basically just prototype each function, creating the bare outline, and then throw it to one of the junior programmers to implement.  (Of course, Simonyi would be the Master Master Programmer.) The term "Master Programmer" was a bit too medieval, so Microsoft went with "Program Manager." Theoretically, this was supposed to solve the Mythical Man-Month problem, because nobody has to talk to anyone else -- every junior programmer only talks to the one program manager, and so communication grows at O(n) instead of O(n2). Well, Simonyi may know Hungarian Notation, but he doesn't know Peopleware. Nobody wants to be a code slave. The system didn't work at all. Eventually, Microsoft discovered that despite the alleged Mythical Man Month, you can still add smart people to a team and get increased output, although at decreasing marginal values. The Excel team had 50 programmers when I was there, and it was marginally more productive than a team of 25 would have been -- but not twice as productive. The idea of master/slave programming was discredited, but Microsoft still had these people called program managers bouncing around. A smart man named Jabe Blumenthal basically reinvented the position of program manager. Henceforth, the program manager would own the design and the spec for products. Since then, program managers at Microsoft gather requirements, figure out what the code is supposed to do, and write the specs. Author: Joel Spolsky admin Sat, 14 Apr 2007 10:26:00 GMT f1397696-738c-4295-afcd-943feb885714:48 https://modernanalyst.com/Resources/Articles/tabid/115/ID/47/Painless-Functional-Specifications--Part-2-Whats-a-Spec.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=47 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=47&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/47/Painless-Functional-Specifications--Part-2-Whats-a-Spec.aspx This series of articles is about functional specifications, not technical specifications. People get these mixed up. I don't know if there's any standard terminology, but here's what I mean when I use these terms. A functional specification describes how a product will work entirely from the user's perspective. It doesn't care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on. A technical specification describes the internal implementation of the program. It talks about data structures, relational database models, choice of programming languages and tools, algorithms, etc. When you design a product, inside and out, the most important thing is to nail down the user experience. What are the screens, how do they work, what do they do. Later, you worry about how to get from here to there. There's no use arguing about what programming language to use before you've decided what your product is going to do. In this series, I'm only talking about functional specifications. Author: Joel Spolsky admin Sat, 14 Apr 2007 10:24:00 GMT f1397696-738c-4295-afcd-943feb885714:47 https://modernanalyst.com/Resources/Articles/tabid/115/ID/46/Painless-Functional-Specifications--Part-1-Why-Bother.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=46 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=46&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/46/Painless-Functional-Specifications--Part-1-Why-Bother.aspx It seems that specs are like flossing: everybody knows they should be writing them, but nobody does. Why won't people write specs? People claim that it's because they're saving time by skipping the spec-writing phase. They act as if spec-writing was a luxury reserved for NASA space shuttle engineers, or people who work for giant, established insurance companies. Balderdash. First of all, failing to write a spec is the single biggest unnecessary risk you take in a software project. It's as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to "wing it." Programmers and software engineers who dive into code without writing a spec tend to think they're cool gunslingers, shooting from the hip. They're not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for. I believe that on any non-trivial project (more than about 1 week of coding or more than 1 programmer), if you don't have a spec, you will always spend more time and create lower quality code. Here's why. Author: Joel Spolsky admin Sat, 14 Apr 2007 10:21:00 GMT f1397696-738c-4295-afcd-943feb885714:46 https://modernanalyst.com/Resources/Articles/tabid/115/ID/73/10-Requirements-Traps-to-Avoid.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=73 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=73&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/73/10-Requirements-Traps-to-Avoid.aspx The path to quality software begins with excellent requirements. Slighting the processes of requirements development and management is a common cause of software project frustration and failure. This article describes ten common traps that software projects can encounter if team members and customers don’t take requirements seriously. I describe several symptoms that might indicate when you’re falling victim to each trap, and I offer several solutions to control the problem. Be aware, though, that none of these solutions will work if you’re dealing with unreasonable people who are convinced that writing requirements is time-wasting bureaucratic overhead. To persuade such skeptics, present data such as that from the Standish Group’s CHAOS report (http://www.scs.carleton.ca/~beau/PM/Standish-Report.html)—a study of 8,380 IT projects which found that more than half were "challenged," with reduced functionality being delivered over-budget and beyond the estimated schedule. The top three contributing factors on challenged projects were lack of user input (12.8% of projects), incomplete requirements and specifications (12.3%), and changing requirements and specifications (11.8%). Author: Karl Wiegers admin Fri, 06 Apr 2007 16:43:00 GMT f1397696-738c-4295-afcd-943feb885714:73 https://modernanalyst.com/Resources/Articles/tabid/115/ID/59/Joint-Application-DesignDevelopment.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=59 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=59&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/59/Joint-Application-DesignDevelopment.aspx Information System Development (or even the broader Information Technology field) is a relatively new discipline compare to matured disciplines like mathematics, physics or philosophy. It is difficult to find an agreed-upon definition on even a widely used term such as JAD. It can mean different things to different people, and it’s constantly evolving. In this article, I will discuss and compare different definition hence different applications of JAD. I will summarize the basic components and benefits of JAD, and guidelines to conduct JAD sessions. I will lastly discuss the new issue with JAD—automation. Author: Mei C. Yatco admin Tue, 27 Mar 2007 03:48:00 GMT f1397696-738c-4295-afcd-943feb885714:59 https://modernanalyst.com/Resources/Articles/tabid/115/ID/41/The-Hard-Work-Behind-Soft-Skills-Closing-the-Gap-Between-Technical-and-Business-Expertise.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=41 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=41&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/41/The-Hard-Work-Behind-Soft-Skills-Closing-the-Gap-Between-Technical-and-Business-Expertise.aspx As outsourcing, global commerce and constantly improving technology continue to change the business world, specialized professionals like scientists, engineers and information technology (IT) workers (including business systems analysts) are increasingly being asked to take on more business-oriented tasks. These tasks can include communicating with executive stakeholders, managing business change, thinking more critically, leading large teams and making complex business decisions. Unfortunately, it's becoming almost universally clear that many technical employees are not equipped with the business knowledge and skills necessary to succeed in this role – or help their organizations reach their strategic goals. This paper examines this phenomenon and offers six crucial focus areas necessary for success in the larger organizational environment. The paper concludes with practical "next steps" for implementing these essential business skills into the repertoire of your technical professionals. Author: ESI International admin Fri, 23 Mar 2007 21:10:00 GMT f1397696-738c-4295-afcd-943feb885714:41